jmap的几个操作要慎用

最近中大招了，前一周开始偶尔在线上发现一些请求时长竟长达7秒，甚至在部分时段系统存在周期性的请求失败或者超时，各种招式都使用了还是不知道确切的原因，百思不得其解，头大的很！昨日晚上发现这个问题简直太严重了，必须要马上处理掉，一会都耽误不得，遂持续奋斗到晚上一点多，早晨7点多又跑起来搞，用各种手段来找到问题的产生规律，一直到下午1点多，才终于发现症结所在了！

应用服务上曾经出现过Load突然升高，并且伴随OOM，遂加上了一个crontab定时任务，通过jmap来检查老年代的使用情况，有到达快fullgc的点就告警出来，好立马人工来检查，上述问题倒是解决了，但是crontab任务没有取消，才有了今天的恶果！

线上服务器怎么能够出现这种低级问题呢？后悔得要命！

以下为从网上转载的一篇文章，也有提到这个，留在这里好随时提个醒！××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××××

转载自：http://hellojava.info/?p=328&utm_source=tuicool

JDK中带有了一堆的工具是可以用来查看运行状况，排查问题的，但对于这些工具还是要比较清楚执行后会发生什么，否则有可能会因为执行了一个命令就导致严重故障，重点讲下影响比较大的jmap。

最主要的危险操作是下面这三种： 1. jmap -dump 这个命令执行，JVM会将整个heap的信息dump写入到一个文件，heap如果比较大的话，就会导致这个过程比较耗时，并且执行的过程中为了保证dump的信息是可靠的，所以会暂停应用。

2. jmap -permstat 这个命令执行，JVM会去统计perm区的状况，这整个过程也会比较的耗时，并且同样也会暂停应用。

3. jmap -histo:live 这个命令执行，JVM会先触发gc，然后再统计信息。

上面的这三个操作都将对应用的执行产生影响，所以建议如果不是很有必要的话，不要去执行。

另外，在排查问题的时候，对于保留现场信息的操作，可以用gcore [pid]直接保留，这个的执行速度会比jmap -dump快不少，之后可以再用jmap/jstack等从core dump文件里提取相应的信息，不过这个操作建议大家先测试下，貌似在有些jdk版本上不work。

之前碰到过一次语言集的问题，我们的Java应用多数在做字符串转码的时候是没有指定编码的，编码信息主要靠启动脚本里面设置LANG来控制，但没想到在某种场景下，竟然有地方设置了LC_ALL，在之前的一篇语言集的文章中，有讲过LC_ALL的优先级是最高的，所以导致启动脚本里设置的LANG失效了，从而导致了乱码，这个Case来看，对于Java应用，还是在启动参数上指定下-Dfile.encoding比较安全一点，避免这种默认的转码依赖系统的配置，很容易踩进坑里。